Remote computing gives a computing system the capability to serve operating system-based applications to terminals and terminal emulators running on PC and non-PC desktops. Such an environment can be a thin-client architecture where application processing occurs mainly on a central server, but can be distributed as well. Because clients requesting access to such applications are available for many different desktop platforms (Macintosh, UNIX, and others), the server provides access to applications from virtually any desktop, and thereby provide enterprises and consumers alike with an extension to their computing environment with a lower total cost of ownership.
For instance, one type of remote computing, called multipoint computer application, enables sharing of applications among computers by allowing a view onto a computer application executing at one site to be advertised within a session to other sites. Such communication is achieved by way of a pre-defined protocol. Each site can, under specified conditions, take control of the shared computer application by sending remote input, such as remote keyboard and pointing device information. It thus enables remote viewing and control of a single application instance to provide the illusion that the application is running locally. Also, some types of “application sharing” remote computing provide for the synchronization, at multiple sites, of multiple instances of the same executing computer application. A session generally includes object(s) executing on one or more client entities which cooperate via a protocol to share one or more applications within the session. Such a protocol defines interactions among client entities and the session. Terminal Server and the Remote Desktop Protocol enable an exemplary remote computing environment.
FIG. 1A generally illustrates how remote computing, like the remote computing of Terminal Server, operates between a server and a client. Server S and client C communicate over any network connection NC, whether wired or wireless. Application A executes on the server S. A user interface, representing operations that can be performed in connection with Application A, is transmitted to the client C. The user interface is then rendered or displayed, e.g., Display D, on client C, and a user of client C can perform operations in connection with server S as if the application were running locally. Input to client C respecting Application A is transmitted back to server S via RDP or another protocol, received by the remote computing server software and the operation respecting Application A is performed on server S on behalf of client C.
Over the last decade, the media rendering functionality of host PCs has been evolving rapidly. Moreover, the number of formats of media, whether audio and/or video, that can be rendered by the host PC has been proliferating. Fortunately, storage has evolved alongside the media desktop to handle the increase in media, whether stored in connection with a streaming experience, or more permanently on disk. Consequently, it is desirable to port the media rendering capabilities of today's host PC desirable to remote devices.
Commonly assigned co-pending U.S. patent application Ser. No. 10/413,846 (the '846 application), filed Apr. 15, 2003, entitled “Application Program Interfaces and Structures in a Resource Limited Operating System,” describes various techniques for remoting a media experience. As discussed in the '846 application, exemplary cooperation among computing devices to transmit a media experience rapidly and in high quality to one or more remote endpoints is shown in FIG. 1B and described below.
FIG. 1B provides a high-level overview of an exemplary operating environment 200 suitable for transmitting media to a remote device. A local PC 201 depicts a computing experience 202, which includes a user-interface component 204 and a media component 206. To transmit the computing experience 202 in high quality, the user interface is communicated through a user-interface channel 210 and the media component(s) 206 are communicated through a media channel 208 via network 211. A remote component 212 receives the user-interface component 204 and the media component 206 through their respective channels. The media and user-interface component are composited to render the computing experience 202 on a remote endpoint 213.
Local PC 201 can be a conventional PC, such as computer 110, as well as a variety of other computing devices. Other exemplary computing devices include a notebook computer, a tablet PC, or a server. Local PC 201 can be any consumer-electronics device capable of rendering media component 206. As will be described in greater detail below, local PC 201 can be used in connection with components to remotely distribute media presentations. Moreover, a DRM scheme enabled by local PC 201 can be applied to the distributed media presentations.
Computing experience 202, in a preferred embodiment, is a media experience that would be observed locally at PC 201. But computing experience 202 should not be construed as limited to a single instantiation. Rather, the present invention contemplates multiple computing experiences 202 that can each be instantiated and received by respective endpoints. Computing experience 202 includes both a user-interface component 204 and a media component 206.
User-interface component 204 includes graphics and images that typically compose a user interface. User-interface component 204 includes icons, host audio, background images and applications such as word-processing applications, spreadsheet applications, database applications, and so forth. Virtually any components that are not media components are part of user-interface component 204. Media Players and associated operating system media components are examples of software utilized in connection with user-interface component 204.
Media component 206 includes media-rich or bandwidth-intensive elements that compose a media event. The following is a nonexhaustive list of exemplary media components: a streaming media presentation, including video and/or audio presentation(s), a television program, including a cable television (CATV), satellite, pay-per-view, or broadcast program, a digitally compressed media experience, a radio program, a recorded media event (sourced by a VCR, DVD player, CD player, Personal Video Recorder and the like), a real-time media event, a camera feed and so on.
Thus, a user with local PC 201 located in a home office could use that PC to watch a streaming video program from the Internet on a television (a first remote endpoint 213) in the family room. Moreover, using the same PC, a child could simultaneously watch on another television set (a second remote endpoint 213) a video stored on local PC 201.
It is noted that these scenarios can be extended to a myriad of circumstances. For instance, a third user could simultaneously observe a camera feed inputted into local PC 201 that is remoted to a third remote endpoint 213. A fourth user could use local PC 201 to remote a fourth instantiation of computing experience 202 to watch a remoted television program on a monitor that does not have a TV tuner.
User-interface channel 210 communicates user-interface component 204 to remote component 212. Terminal Server and Terminal Client Services, offered by Microsoft Corporation of Redmond, Wash., provide an exemplary user-interface channel 210. Any remotable protocol can be used to transmit data through user-interface channel 210. Exemplary protocols include the T-120 series protocol and HTTP (Hyper Text Transfer Protocol).
Media channel 208 is separate from user-interface channel 210. Media channel 208 is used to transmit bandwidth-intensive experiences such as video and others listed above. Media component 206 provides a communications conduit for data to flow separate from user-interface component 204. Thus, the media component 206 is sent out of band with respect to the user-interface component, but synchronized. An exemplary protocol to transmit data through media component 206 includes, but is not limited to, the Transmission Control Protocol (TCP).
Network 211 can be any communications network, but is described in the context of a local area network (LAN). Today, LANs are offered in many varieties, including Ethernet, phone-wire networks, power-wire networks, and wireless networks. Wireless networks are not limited to radio and spread-spectrum networks and utilize protocols such as 802.11a, 802.11b, and 802.11g. An ordinary skilled artisan will readily appreciate these and other networks can also be used.
In each of the scenarios mentioned above, user-interface component 204 is presented on the respective remote endpoint 213 along with media component 206. This enables a remote user to remotely operate local PC 201. Typical actions that a remote user may desire to carry out include commands such as stop, fast forward, and rewind as well as conventional computer commands that enable actions such as resizing replay windows and adjusting volume and picture quality. In theory, it would work to have a standard set of input commands from which the user of a remote media device could choose, if remote media devices were standard, but as illustrated in FIG. 1C, both remote media devices and media types are diverse groups.
For exemplary purposes only, FIG. 1C illustrates that there are many kinds of media, such as music (MP3s, WMAs, etc.), streaming audio/video, photos (JPEGs, GIFs, etc.), movie files (MOVs, MPEGs, etc.), advertisements, broadcast media (radio, TV, cable, etc.), graphics data, etc. FIG. 1C also illustrates that there is a variety of devices that render media in some fashion, for some purpose. These devices include, but are not limited to, televisions, radios, tuners, DVD players, VCRs, MP3 players, Smart Display devices, laptops, gaming machines, remote control devices, cell phones, PDAs, digital picture frames, etc. The exemplary, non-limiting links between the media types and devices illustrate that each of the types of devices may or may not have the ability to render the type of media in question. Thus, the media rendering capabilities of the remote devices are diverse. Moreover, even if a device supports the ability to render a particular format, there is still a difference between the user interface capabilities presented at a host device versus the capabilities of a user interface presented at the remote device. It would be desirable to have a user interface abstraction layer for the translation of the user interface capabilities from the host device to the remote device.
For instance, an MP3 player may or may not be able to store or render video. A laptop may have significantly better storage, processing power and resolution than other devices. A universal remote device may have specialized touch screen capabilities. Thus, a user would benefit from automatic tailoring of the desktop media experience familiar to the user in a custom format that makes sense in view of the media capabilities of a select remote device. Today, no such ability exists, unless a developer hardwires unique server software and unique client software for achieving the objective with respect to a specific device.
It would thus be desirable to have a mechanism or framework for a remote device to declare its media rendering capabilities to a host device. It would be further desirable to have a mechanism or framework for a remote device to declare its user interface capabilities to a host device as they relate to the remote device's media experience. Accordingly, there is a great need in the art for a remote computing mechanism, enabling a remote device to declare capabilities as they relate to media in a computing system including at least one host device, and one or more remote devices.